ci: check the upstream base ref instead of pushing it - #13
Merged
Conversation
The upstream-base job force-pushed the pinned upstream commit to refs/heads/upstream-base with GITHUB_TOKEN. That commit carries upstream's own .github/workflows/ files, and GitHub refuses workflow-file writes from an App token without the workflows permission, which no permissions: block can grant. The push has been failing since the base moved to v24.20.0. Automating it needs a PAT or deploy key with write access to this repo, stored as a secret, for a push taken once per upstream bump. Not worth the exposure. Make the job read-only: compare the two ls-remotes and, on a mismatch, print the commands a maintainer runs by hand. It now runs on pull_request too, so a bump PR surfaces the requirement before merge rather than at release time.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
upstream-basejob force-pushed the pinned upstream commit torefs/heads/upstream-baseusingGITHUB_TOKEN. That commit carriesupstream's own
.github/workflows/files, and GitHub refuses workflow-filewrites from an App token unless it holds the
workflowspermission — a scopeno
permissions:block can grant. The job has been failing since the basemoved to v24.20.0, with
refusing to allow a GitHub App to create or update workflow .github/workflows/build-tarball.yml without workflows permission.Automating the push means storing a PAT or deploy key with write access to
this repo, for a push taken once per upstream bump. Not worth the exposure,
so the job becomes read-only: it keeps the two
ls-remotes and no-ops whenthey match, and on a mismatch prints the resolved SHA and the fetch + push a
maintainer runs by hand, then fails. Permissions drop to
contents: readandthe token env is gone.
It now also runs on
pull_request— that guard existed only because the jobwanted
contents: write, and a bump PR is where you want to learn the basestill needs pushing, rather than at release time. A bump PR will show this
check red until the ref is pushed, which can happen any time from the moment
the PR opens; nothing reads the branch except a release run.
refs/heads/upstream-basehas already been pushed to v24.20.0 by hand, so thecheck passes as of this PR. Docs in RELEASING.md and UPGRADING.md described
the job as moving the branch and are updated.